Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/001306_daemon _Wed Jun 16 01:39:07 1993.msg

Internet Message Format | 1994-01-24 | 5KB

Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA05513; Wed, 16 Jun 93 01:39:10 MET DST
Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA05509; Wed, 16 Jun 93 01:39:07 MET DST
Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA26775; Wed, 16 Jun 1993 02:01:15 +0200
Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA37602; Tue, 15 Jun 1993 18:58:50 -0500
Date: Tue, 15 Jun 1993 18:58:50 -0500
From: [e-mail] (Michael Grobe)
Message-Id: <[e-mail]>
To: [e-mail]


dave:

thanks for your reply. it was very helpful.  i have a couple of comments.

first, i mentioned that we are planning to use something like:
      <link rev=made href="mailto:...whatever..." >
to allow info providers to provide a path for readers (through their
clients) to contact them with comments.  note that this is a (static) "link"
rather than an (executable link, or) anchor, whereas your MSG tag is an
"executable" link.  lynx will support a command that will search out
the static info and open a mail screen for the user with the address already
in place.  (actually, lynx already supports such a command when displaying
files in its native hypertext format, and we have found this so useful
that we feel we must duplicate it as we convert our documents to html
this summer.) so, even though MSG is a better solution, we can't wait.

also with respect to the markup of tables, it seems to me that it would be
useful to allow more explicit control over display of the headers, separately
from the body of the table.  that is, i might want to set up headers
that are not centered, but rather left- or right-justified.

for example, suppose you want to mark up this table:

            average         maximum
          height in         weight in
              yards         metric tons

 males       1.9               .003
 females     1.7               .002


you could allow complete control over the header format by allowing
a second cols attribute applicable to only the headers, or, if you
didn't want to allow complete control you could just add
a placement attribute to specify center, left, or right justification,
giving a <dl> structure that would look something like:

   <dl cols="C7N1.1N0.3">
      <dthd>                       <! null column header >
      <ddhd right> average         <!-- first header line -->
      <ddhd left> maximum
      <dthd>                     <! null column header >
      <ddhd right> height in         <!-- second header line -->
      <ddhd left> weight in
      <dthd>                       <!third header line>
      <ddhd right> yards
      <ddhd left> metric tons
  <dt>males <dd> 1.9 <dd> .003
  <dt>females <dd> 1.7 <dd> .002


the renderer would set up the right justified
headers so that the longest header was centered over the data,
and the shorter headers were right justified with the longest one.

further, i suspect the renderer would center over the displayed
data rather than with respect to the designated columns.  the column
sizing is a matter of a maximum width, and may not even be close to
the width of the bulk of the data to be displayed. in this regard
the "cols" attribute may be more like a "datatype" than a format.
on the other hand, this would require an initial inspection pass.

>ISSUE: Is it a bad idea to overload definition lists for tables?

i think it would be easier for beginning users to have two separate
constructs, one for description lists and one for tables.  i know that
users building description lists could simply ignore the extra features
(if their teachers and the documentation they read can resist trying
to tell them about all the extras!), but all users marking up tables
would have to deal with the description list mnemonics.  if you
develop a <table> tag, you could get away from the dt and dd distinction
(if you so choose) or at least use something with better mnemonic
value for the user thinking s/he is marking up a table (or relation) rather
than a "description list".

the first element of a table is (strictly speaking) no different from
the others (a table is simply a set of tuples) and, since
some tables have line-label information on the right and may even
have it in some other column or not at all, calling the first column
a "description term" may actually confuse the user.  i suppose that you
will still have to have a different tag to mark the start
of a new record, of course, so you would end up with a <table> structure
looking something like:

  <table cols="C5N6.2EL20">      <!-- just an example datatype-->
  <ch center|left|right s=n> text <h c|l|r s=n> text  <h c|l|r s=n> . . .
  <ch c|l|r s=n> text <h c|l|r s=n> text <h c|l|r s=n> . . .

       . . .

  <row>  data    <comma>  data    <comma> . . .
  <row>  data    <comma>  data    <comma> . . .

       . . .

  </table>

here again, some kind of style attribute might be useful, by the way.
and yes, that is one of those "comma" delimited lists you have heard
about.  i couldn't think of anything more mnemonic.

:michael grobe